1. Field of the Invention
The present invention relates generally to a call processing system and method based on an answer mode of a PoC (Push-to-Talk over Cellular) user.
2. Description of the Related Art
With the development of mobile communication systems and the expansion of mobile communication networks, mobile phone services and applications have diversified and expanded accordingly. For example, although mobile communication systems were originally only required to provide simple communication services (e.g., voice-only communication services), mobile communication systems today provide diversified services (e.g., location services, a multimedia services, PTT (Push-to-Talk) services, etc).
Currently, PTT services include various additional functions such as an instant messenger function, a status indication function, etc., in addition to existing voice communication functions which are provided by radio sets, TRSs (Trunked Radio Systems), etc.
Currently, efforts are being made to enact a standard for a PTT over Cellular (PoC) service using a mobile communication network. The PoC service has various features which distinguish it from existing mobile communication services. For example, an OMA (Open Mobile Alliance), a group that defines specifications designed for mobile communication services, has set forth standards which specify that a user of a mobile communication device should be allowed to make a call while moving between a plurality of sessions.
Hereinafter, a structure of a general PoC service system will be described.
A block diagram illustrating a general PoC architecture is shown in FIG. 1. A PoC client 10 is a service requester that is mounted in a mobile phone, and is usually connected with a SIP/IP (Session Initiation Protocol/Internet Protocol) core 30 via an access network 20, wherein the SIP/IP core is a core element for supporting both SIP and IP multimedia.
Here, the PoC client 10 provides access to a PoC service while residing in a PoC user terminal. The PoC client's 10 main functions are establishing a PoC session, participating in an existing PoC session, and terminating the established PoC session. In addition, the PoC client 10 performs other functions such as creating and sending a talk burst, supporting an instant personal alert, performing authentication on obtaining access to the PoC service, and so forth. Hereinafter, unless otherwise indicated, the term “PoC client 10” refers to a PoC service subscriber.
The SIP/IP core is connected with a PoC server 60, a GLMS (Group List Management System) 50 and a presence server 70 in order to support the PoC service, thereby providing the PoC service.
Here, the PoC server 60 may perform a Controlling PoC Function (CF) for maintaining and managing the PoC session, a Participating PoC Function (PF) for participating in the PoC session which is established for a one-to-one communication or a many-to-many communication, and so forth.
To be specific, the CF maintains and manages the PoC sessions, and the PF takes charge of maintenance and management of each PoC session. Moreover, although the CF and the PF are different functions which are performed by the PoC server, the PoC server may perform the CF and the PF at the same time. The CF and the PF will be described in more detail with reference to Table 1 and Table 2.
TABLE 1Controlling PoC Function (CF)Provides centralized PoC session handlingProvides the centralized Media distributionProvides the centralized Talk Burst Arbitration functionalityincluding talker identificationProvides SIP session handling, such as SIP session origination,termination, etc.Provides policy enforcement for participation in group sessionsProvides the participants' informationCollects and provides centralized media quality informationProvides centralized charging reportsMay provide transcoding between different codecsSupport Talk Burst Control Protocol Negotiation
As illustrated in Table 1, the CF manages PoC sessions on the whole, particularly to receive, sequence and authorize right-to-speak (i.e., a floor) requests of the PoC clients, to distribute a talk burst requested by an arbitrary PoC client to all the other PoC clients participating in a group calling, and to provide information about the PoC clients participating in the group calling.
As in Table 2, the PF serves to manage the PoC session connected with the CF and each PoC client, particularly, to relay a floor when the PoC client requests the floor or when the CF assigns the floor to the PoC client. Further, the PF serves; (1) to relay media between the CF and the PoC client; (2) to perform transcoding when different codecs are used between the CF and the PoC client; and (3) when two simultaneous sessions are established, for example when a PoC user is invited to the other session while participating in one session, to filter any one of the sessions according to selection of the PoC user.
TABLE 2Participating PoC Function (PF)Provides PoC session handlingMay provide the media relay function between PoC Client andControlling PoC serverMay provide user media adaptation proceduresMay provide the Talk Burst control message relay function betweenPoC Client and Controlling PoC serverProvides SIP session handling, such as SIP session origination,termination, etc, on behalf of the represented PoC Client.Provides policy enforcement for incoming PoC session (e.g. accesscontrol, incoming PoC session barring, availability status, etc)May collect and provide media quality informationProvides the participant charging reportsMay provide filtering of the media streams in the case ofsimultaneous sessionsMay provide transcoding between different codecsMay support Talk Burst Control Protocol NegotiationStores the current Answer Mode and Incoming PoC Session Barringpreferences of the PoC Client
In the PoC system configured as mentioned above, a certain PoC user can input information on groups of other PoC users and their members into the GLMS 50 by means of the terminal of the PoC user, or can ascertain information about the other PoC users who can be called out through an individual or group list received from the GLMS 50. Moreover, another method capable of generating, correcting and managing the groups and their members at the GLMS can input such information through a communication network, such as the Internet, an intranet or so forth.
In order to make use of a PoC calling service, the PoC user registers his/her PoC address with the SIP/IP. At this time, the SIP/IP core stores information on the PoC user on the basis of a request of the PoC user. Therefore, when another PoC user attempts a PoC group calling, the other PoC user registers its own information with the SIP/IP core in advance as set forth above, and provides a request for the calling to the SIP/IP core by using the group identification information received from the GLMS. Here, the SIP/IP core goes through the processes of determining the address and positioning a domain by using the information about the requesting PoC user, and then sends a request for PoC communication to a home PoC server with which the requesting PoC user is registered. The PoC server prepares an opening of the PoC session with regard to the PoC communication request, obtains information about each PoC user from a GLMS server, and sends a communication request signal to the corresponding SIP/IP core. At this time, in the case of the communication request of the users within an intra-domain, the PoC server performs the PF and the CF. The PoC server managing the PoC user provided with the communication request goes through the process of locating the SIP/IP core by using the information about the PoC user which is sent to the PoC server, and then makes the communication request to the PoC user.
Hereinafter, the call processing for a PoC communication setup will be described according a reception-side viewpoint and a transmission-side viewpoint. Features of the PoC system which are required according to the OMA for each of the reception and transmission side setups are as follows. First, an answer mode can be set according to a request of the PoC user. The answer mode can be generally divided into an auto-answer mode and a manual answer mode.
In the auto-answer mode, when a certain sender is included in a list of the PoC users designated to make an auto-answer on the reception side, an auto-answer is immediately sent to the transmission side in the network instead of a manual answer of a receiver.
Meanwhile, the manual answer mode is applied when the sender is not included in the list of PoC users for the auto-answer, when the sender is not known or when the receiver is set to manually answer all the PoC users, which means that a PoC communication request is sent to a user's terminal via a receiving network, and thereby the communication is connected by permission of the PoC user. Here, each of the answer modes and list information are set and stored in the PoC server belonging to a home network of each of the respective PoC users.
Second, the PoC system is divided into an on-demand session mode and a pre-established session mode according to whether the PoC client is connected with a PoC server within the home network of the PoC user.
The pre-established session mode means that the PoC user establishes a specific session in advance (i.e., establishes an early session) between the PoC client and the PoC server belonging to the user's home network at the request of the user. This pre-established session is required for a fast communication setup. To this end, the PoC user previously negotiates with the PoC server to define server-client media parameters that the PoC user intends to use, so that it is unnecessary to re-negotiate at a later time and set server-client media parameters to be used in the future. In order to establish the early session, the PoC client provides the media parameters supported to a Session Description Protocol (SDP) body through an SIP INVITE method, and makes a response to the media parameters provided from the server, thereby returning, to the PoC user, identification information of the early session which is newly set to the response message from the server together with a conference URI (Uniform Resource Identifier). In the case of making use of this early session, it is possible to previously set an IP address, a port number, a talk burst control protocol for controlling a codec, and a talk burst that are to be used, and so forth.
The on-demand session mode refers to a state where the PoC user does not establish the early session, and means that the PoC user receives an INVITE message of another PoC user to then perform a PoC call connecting procedure.
Meanwhile, the PoC specification that is being standardized by the OMA includes the following special features except the basic functions of the communication system as mentioned above.
First, the PoC system supports a function of a Manual Answer Override (hereinafter referred to as “MAO”) which sends an auto-answer to an authorized PoC user which is previously set by a PoC receiver (or a reception side PoC user) regardless of the answer mode of the PoC receiver and connects communication at a receiving terminal. A request of the MAO is supported only to an authorized communication requester, and is sent with an MAO indication included in a PoC communication request message (or INVITE). This MAO request is devised for public services and for emergency services (e.g., police, fire, accident, disaster relief, other emergencies, etc.)
Moreover, the PoC system allows both the PoC server as an element on a network and the PoC client as a terminal of the user side, to set the answer mode to the communication request.
When being set in the network, the answer mode is implemented at the PoC server that performs the PF within a home network to which the PoC client belongs. In this case, it is characterized in that the communication requesting procedure can be simplified as compared with the case wherein the answer mode of the PoC client is reflected on the PF which is connected to the PoC client, and then an answer is made.
Finally, the PoC user can set the answer mode by using its own client. At this time, it is characterized in that the answer mode of the PoC user's own client has priority over the answer mode set on the network. This is for solving a privacy problem which occurs when the PoC user changes its own answer mode by using the terminal to request the PoC server to update the answer mode, particularly when the answer mode is not reflected in real time due to a signal delay or error in a radio access network or an IP core network. In order to solve this privacy problem, the PoC service can set the answer mode of the user for both the PoC server and the PoC client, and the PoC server and the PoC client perform operations as determined by the answer mode of the PoC client which complies with a user's desires.
Depending upon various functions and features of the PoC system, the call processing may be variously performed. Particularly, in the present invention, when the pre-established session is provided on the PoC call reception side and when the one-to-one communication of requesting the MAO on the PoC transmission side is requested, the process and or method for complying with the call request and performing the call processing is performed.
In reality, requesting the MAO on the PoC transmission side is usually occurs during emergency situations. In the process of actually requesting the MAO on the PoC transmission side, unnecessary steps are performed, which causes an unnecessary time delay. This unnecessary time delay will now be discussed with reference to the transmission side and to the reception side of conventional systems.
A flow chart illustrating a conventional process of setting a reception side PoC communication for an MAO is shown in FIG. 2, and a flow chart illustrating a conventional process of setting a transmission side PoC communication for an MAO is shown in FIG. 3. As shown in FIGS. 2 and 3, call processing procedures of call transmission and reception sides are illustrated for a conventional communication system in which a PoC communication sender makes a request for call processing based on an MAO indication and when an early session is established on the reception side.
With reference to FIG. 2, a PoC client A sends an INVITE request to a SIP/IP core A, wherein the INVITE request includes information on a SIP address of a receiver which the PoC client A wants to invite (Step 101).
Here, the INVITE request includes an information element indicating the MAO, and is sent to a Participating PoC server A via the corresponding servers (P-CSCF (Proxy-Call Session Control Function) and S-CSCF (Serving-Call Session Control Function)) within an IMS core network by means of a query about a path in a DHCP (Dynamic Host Configuration Protocol) server or a DNS (Domain Name System) server (Step 102).
On making a request for a general call, the Participating PoC server connected with a PoC user may be separated from a Controlling PoC server for managing a talk burst of an opened session. Hence, the INVITE request sent in Steps 101 and 102 is sent to a Controlling PoC server X via a SIP/IP core of each network (Steps 103 to 105).
The Controlling network including a CF (not shown) sends the INVITE message sent in Step 105 to the corresponding SIP/IP core, and then receives a response message. A SIP response message from the reception side network may be a provisional response message, a successful response message, or an error message. These messages each comprise a 3-digit code. For example, the provisional response message comprises a 3-digit code beginning with a 1 such as 1xx; the successful response message comprises a 3-digit code beginning with a 2 such as 2xx; and the error response messages comprise a 3-digit code beginning with a 4, a 5, or a 6 such as 4xx, 5xx and 6xx. These codes are described below with reference to Table 3.
However, within the fundamental spirit and scope of the present invention, the normal call processing procedure will be mainly described.
TABLE 3Response Status CodeInformational100Trying180Ringing181Call Is Being Forwarded182Queued183Session ProgressSuccess200OKRedirection300Multiple Choices301Moved Permanently302Moved Temporarily305Use Proxy380Alternative ServiceClient-Error400Bad Request401Unauthorized402Payment Required403Forbidden404Not Found405Method Not Allowed406Not Acceptable407Proxy Authentication Required408Request Timeout409Conflict410Gone413Request Entity Too Large414Request-URI Too Large415Unsupported Media Type420Bad Extension480Temporarily not available481Call Leg/Transaction Does Not Exist482Loop Detected483Too Many Hops484Address Incomplete485Ambiguous486Busy Here487Request Terminated488Not Acceptable HereServer-Error500Internal Server Error501Not Implemented502Bad Gateway503Service Unavailable504Server Time-out505SIP Version not supportedGlobal-Failure600Busy Everywhere603Decline604Does not exist anywhere606Not Acceptable
After Step 105, the CF of the controlling network may receive an auto-answer or a manual answer, particularly an OK response. Alternatively, in the case of the auto-answer as in FIG. 2, a 183 Session Progress signal (the provisional response signal) (not shown) may be received, and thereby a connection between the PoC server and the PoC client may be performed in the IMS network of the communication requester. A communication permission signal of the receiver responds with the final OK response, and is sent to the PoC client A via the CF and the PF of the PoC server (Steps 106 to 110). Meanwhile, the CF receives an OK response signal of the receiving client, and then determines that a PoC communication is connected. As a result, the CF sends a Floor granted signal that assigns a talk burst floor to the PoC client A.
The PoC client A receives the OK response and Floor granted signals with respect to the INVITE request signal, and then sends a Send talk burst signal first by using a RTCP (Real-time Transport Control Protocol), wherein the Send Talk Burst signal indicates that a user of the PoC client sends the talk burst prior to making the user hear a ring back tone. Here, the Send Talk Burst signal includes information including a PoC address, a display name etc., of the transmission side PoC client. Because the Send Talk Burst signal makes use of a path of a media bearer, it can be sent without passing through the SIP/IP core network.
After sending the Send talk burst signal, the PoC client informs the user of the communication connection and sends media (typically, a voice) of the user by using the RTP.
FIG. 3 is a flow diagram illustrating a reception side call processing procedure according to the prior art when an early session is established which corresponds to a transmission side communicating procedure and an MAO request is sent.
A procedure where the INVITE message including the MAO request is sent to the PoC server belonging to a home network of the reception side PoC client via the SIP/IP core according to the call processing procedure of the IMS network is shown in Steps 201, 202 and 203.
At this time, a Participating PoC server B may have a setting value of its own answer mode, i.e., has a parameter of any one of its own auto- and manual-answer modes. However, the Participating PoC server B checks an MAO indication in the INVITE request message, and then sends an auto-answer message to the call request network (Steps 204, 205 and 206).
In general, this auto-answer message is the SIP message called the “183 Session Progress” as mentioned above, which is sent to a Controlling network. The Participating PoC server B sends an INVITE or re-INVITE request message to the PoC client having the corresponding PoC address which was sent in Steps 204, 205 and 206 (Steps 207 and 208). Steps 207 and 208 serve to inform the PoC client that a PoC call request of making a request for the MAO is received. The PoC client B then automatically sends an OK response without confirmation by the PoC user (Steps 209 and 210).
The Participating PoC server B receiving the corresponding OK response sends a response message responding to the MAO INVITE to the transmission side network to complete the PoC call processing procedure (Steps 211 to 215). The PoC Server X sends a Receiving talk burst signal to PoC Server B (Step 217). The PoC server B then sends the Receiving talk burst signal to the PoC client B, wherein the Receiving talk burst signal includes the PoC address and display name of a person who makes the PoC communication before the PoC client sends the media (Step 217).
Finally, the media (voice) sent on the transmission side is sent to the PoC client B by using the RTCP by means of the connected media bearer, so that the communication is initiated.
FIG. 4 is a table which illustrates information included in an INVITE request of a PoC call.
It can be seen that information elements included in the INVITE message requested on the transmission side include (1) PoC addresses of PoC call requester, (2) media parameter information presented at the client and server, (3) an indication informing a PoC service, (4) PoC addresses of PoC call receiver, (5) an indication set at the PoC server, (6) a talk burst control protocol to be negotiated with each other at both ends of the transceiving network and so forth, and (7) alternatively an MAO (Manual Answer Override) indication.
The procedure of processing the MAO communication request with respect to the client having the early session as set forth in the prior art includes the procedure of checking the MAO request indication at the PF to send the auto-answer, but it does not have a great influence on the final PoC communication connection between the transmission side network and client. In the procedure of processing the MAO communication request, after the OK response message received from the client arrives at the CF and the transmission side network, both connection of the media bearer and transmission of the Floor granted signal for making the actual PoC communication are performed.
However, the communication request message including the MAO is characterized in that it can be processed regardless of the answer mode of the reception side user, and has a function of sending the talk burst transport message by using the RTCP packet so as to display the PoC address information and display name before the media is sent to the reception side client. For this reason, the conventional procedure as shown in FIG. 2 cannot be referred to as an optimized procedure of the MAO call processing due to repetitive request-response signaling. In particular, for emergency and public use purposes, quick call processing is desirable.